docs: add an SSH tunnel configuration guide - #551

The cookbook offered three deployment scenarios, but "tunneled" was never
a third place to deploy interLink - it is an in-cluster deployment where
the plugin happens to sit on the remote system and the API server reaches
it over an SSH tunnel. The API server is in the cluster either way.

So the cookbook now has two pages, and the in-cluster one covers both
variants:

  - plugin in the cluster, reaching the batch system itself (shared
    filesystem plus SSH shims, or a remote API)
  - plugin on the remote system, reached through the ssh-tunnel binary
    over a Unix socket

3-tunneled.mdx is removed and intro.mdx updated to match, including the
dead link to it.

Most of that page was systemd boilerplate already covered verbatim by the
systemd guide - service user creation, log rotation, health checks,
service management. Dropped, rather than duplicated a third time. What
was genuinely tunnel-specific moves with it: the ssh-tunnel unit and its
ordering constraint now live in the systemd guide, and the authorized_keys
and sshd_config restrictions stay on the cookbook page.

Two things worth flagging for review:

The in-cluster page now mentions SSH twice, for unrelated reasons: the
ssh-tunnel binary carries interLink's control plane, while the SSH shadow
carries traffic into an already-running offloaded pod. There is an admonition
drawing that line, because conflating them would be easy and expensive.

The page also ends with a short comparison of the three ways to reach a
service inside an offloaded pod - wstunnel, ssh, full mesh - and what each
one needs from the site, pointing at the respective guides rather than
explaining them again.

Cookbook sidebar_position values were all 3, so the pages were ordered by
filename; edge and in-cluster are now 1 and 2.

Docs build passes with onBrokenLinks: throw.

Signed-off-by: Matteo Bunino <48362942+matbun@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Validating the SSH shadow against a real site turned up the one prerequisite the
guide never named: sshd has to permit TCP forwarding for the account. Sites that
set "AllowTcpForwarding no" globally and re-enable it per group are common, and
the failure is silent until traffic arrives — the shadow starts, reports Ready,
and then resets every connection with only "administratively prohibited" in its
log.

Add a prerequisites section with a check to run before deploying, the two other
things the login node has to provide (a route to the compute nodes on the exposed
ports, and inbound SSH from the cluster), and a troubleshooting entry keyed on the
exact error string.

Signed-off-by: Matteo Bunino <48362942+matbun@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Sites that refuse TCP forwarding now have an option other than "ask the site":
Network.SSH.ForwardMode: exec relays each connection through a command on the
login node. Describe both modes side by side, what each needs from the login
node, and the two things that decide whether exec is usable at a given site --
which netcat is installed, and whether the site tolerates a process per
connection.

Point the prerequisites and troubleshooting entries at it, so the reader who
just hit "administratively prohibited" lands on the alternative rather than a
dead end.

Signed-off-by: Matteo Bunino <48362942+matbun@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Three things the guide described as they were before deployment testing changed
them, each of which a reader can now hit and find nothing about.

The compute node section stopped at "the tunnel starts". It now also covers a
requeued job moving the tunnel in place, which is a log line an operator will see
and should not read as a fault, and states what a plugin is allowed to report:
interLink refuses anything that is not a hostname or an IP, because the value ends
up as an ssh argument, so a plugin returning something else fails in a way worth
naming.

Credential replication gained a marker and a refusal. A name collision in a
shadow namespace now fails pod creation instead of destroying whatever was there,
which is a message someone will search for.

Two matching troubleshooting entries, both keyed on the exact log line.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Matteo Bunino <48362942+matbun@users.noreply.github.com>